时隔一年，我开始了系统分析师的博客写作。回过头翻看一下，一年前的系统架构设计师系列的第一篇博客-需求理论，还是比较有感触的。
其实系统分析师的考试早在上边年五月份就参与了，也在六月份就知道自己通过了考试。但是一方面系统分析师与系统架构设计师有很多内容上的重复，另一方面自己确实工作也比较忙，所以相关的博客就搁置下来了。
正好最近有点空闲时间，正好一方面整理所学，一方面输出一些博客，帮助大家。
分析师与架构师首先，就是探讨一下，系统分析师与系统架构设计师的关联与区别。
两者都是软件考试的高级考试科目，并且也是相似度最高的两门高级科目。毕竟早期软考只有系统分析师的考试，而系统架构设计师是由于系统架构设计内容不断增多，然后分离出来单独成为一个科目的。
很多朋友都无法把握住两门考试科目的区别，导致学习无法集中注意力，从而造成考试失利。
考试角度首先从考试角度来说，系统分析师中有关架构的部分，分值比较低，可以说几乎与企业信息化等章节一样，就是个普通公民，不再享受系统架构设计师考试中一等公民的待遇了。其次，系统分析师由于在架构方面的分值大幅下降，所以提高了所有章节的分值。简单说，就是所有章节的考试内容变多了。虽然深度不再深挖，但是考试范围的扩大，导致考生觉得系统分析师内容太过繁杂，准备困难，难以把握重点。
那么，分析师有没有类似架构师的重点呢？答案是有的。从考试的分值散布（客观，案例，论文综合起来看），以及考试名称——系统分析师，可以知道重点在分析。就像系统架构师的重心在架构，高项的重心在管理，分析师的重心在分析。当然了，由于系统分析师的特殊性（所有高级科目的源头），所以它的重心不会如架构师，管理师那样突出。
那么落在考试章节中，分析又落实在哪里呢？那就是系统规划，需求分析，以及一些零散的涉及分析的内容。当然，如果你是第一次参与高级考试，可千万别只看这两个章节啊。
现实角度老规矩，从考试的角度分析后，我们来从现实角度分析一下。当公司规模不大的时候，公司技术方面往往就一个技术部。技术部会有一个负责人，他会负责所有技术相关的问题，包括但不限于：
技术顾问：负责解答公司高层对技术的疑惑技术评估：参与公司项目，产品的技术评估技术规划：为公司的战略目标，提供技术方面的长远规划技术管理：为领导的技术部门进行有效管理技术支持：为领导的项目提供技术的直接帮助公司规模不大的时候（百人以内，技术部门二十人以内），负责人尚且还能支撑得住，能够在各方，各个工作间周转开。不要问我怎么知道的，问就是我在上家公司就是做这些的。
但是随着公司规模增大，技术部门的人数增长。技术负责就不可能面面俱到了（某些牛人，就算了，咱只说正常情况）。
到了这个时候，原有技术负责的工作必须进行拆分。在中型公司，比较常见的是采用矩阵型的组织结构，原技术负责的职责拆分为：
技术总监：负责技术顾问，技术规划项目经理：负责项目管理工作技术负责：负责单个项目的技术支持，配合项目经理与技术总监，完成技术评估，配合技术总监完成技术规划的落地。（这其中的需求，往往是三方的协调，妥协的一个结果。如果不懂得这句话，可以等到我开启项目管理的分支，再细谈。或者私聊我）
不要问我怎么知道的，问就是因为年中有一个以前的上司来挖我的时候，和我提到了他们公司的情况。
可能你们要说，还是没有看到系统分析师啊？别急，马上就到了。
随着项目规模的扩大，项目内的技术负责压力就比较大了。一方面需要技术上司，业务方，项目经理打交道，了解具体需求，进而进行分析，另一方面还需要进行项目信息系统的架构设计，搭建，为下属提供技术支持。所以，部分大型公司就再次将技术负责拆分为业务分析师与技术架构师，也就是大家说的BA和架构师。不要问我怎么知道的，问就是这个月，打电话挖我的公司就有这么做。当然，也有人注意到，需求这个东西不是应该交由项目经理处理嘛？怎么说呢？一方面，有些需求只有技术人员才有那个敏感性，另一方面，项目经理虽然也有获取需求这一过程，但并不表示只靠项目经理自己去获取，